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A co.put.r conf.r.ncing .y.t.a per.it. Individual 
work.tation., capabl. of communication with oth.r .t.tion. 
by M «n. of t.l.comminication or network link, of div.r.. 
typ.., to participat. in a conf.r.nc. through a dynamic 
n.tvork vhich th.y may .„t. r er 1#av . at win ^ 
participating .tation mi.t be abl. to ..tabli.h at l.a.t 
on. and pr.f.r.bly at l.a.t two independent phy.ical 
co— unication link, with oth.r .tation., and maintain, a 
n.twork routing tabl. .toring data a. to oth.r .tation. to 
vhich it 1. logically connected dir.ctly or lndir.ctly 
through .tation. to which it i. phy.ically conn.cfd. On 
••tabli.hing a phy.ical conn.ction to anoth.r .tation it 
transit, data to that .tation ba.ed on th. cont.nt of it. 
routing t.bl. and r.c.iv.. data based on th. cont.nt of th. 
other .tation'. routing tabl.. it al.o trans.it., to oth.r 
•tation. to which it i. logically connected, data r.lativ. 
to change, in it. logical .tatus, and receive, data a. to 
chang.. in th. logical .tatu. of other .tation. within th. 
n.twork, and updates it. routing tabl. accordingly. 




conferencing situations which may require communication 
between unconnactad and possibly dissimilar networks and 
stand alona stations. 

IBM Technical Disclosurs Bulletin, Volume 28, 
5 Number 3, A u oust 1985, discloses a dynamic conference 
calling configuration, which however depends upon a 
topology in which nodes are arranged in a ring around which 
data packets circulate, with nodes being Inserted into and 
deleted from the ring. 

10 Dynamically reconf lgurabla networks are known for 

example from U.S. Patents Nos. 4,745,597 (Morgan et al) , 
4,754,395 (Welsshaar et al) and 5,048,014 (Fischer). Such 
arrangements cannot provide for communications outside of 
the physical architecture of the network. 

15 U.S. Patent No. 4,872,197 (Pemmaraju) discloses a 

dynamically configurable communications network, reliant 
however on the provision of nodes to be networked with a 
specialized communications coprocessor which establishes 
communication with other like processors according to a 

20 specific protocol. 

An object of the present invention is to equip 
stations having suitable communications facilities, whether 
by means of a computer network to which the station is 
connected or other telecommunication facilities, with the 

25 capability of entering and leaving a dynamic network of 
stations forming a conference in a manner which is 
substantially hardware in dependent provided that the 
station has the capability to establish a bidirectional 
messaging link with at least one other station of similar 

30 capabilities within the network. 



According to tho invention th.ro i. providod • 
co.put.r work.t.tion with th. capability of participating 
•t phyaical and logical l.v.l. in a co«putor conf.r.ncing 
network, co.pri.ing: at loaot on. ..an. for ..tabli.hing 
3 and di.continuing a bidir.ctional phy.ical ....aging 
conn.ction with anoth.r .tatlon having .iailar capability 
and with which it i. dooirod to n.twork, according to a 
protocol p.rmitting th. ..tabli.hmant of .uch a conn.ction 
r..pon.iv. to a protocol l.v.l r.gu..t; ..ana ..tabli.hing 
10 a n.twork routing tabl. at th. .tation storing data a. to 
oth.r .tation. to which it 1. dir.ctly phy.ically 
conn.ct.d, and a. to oth.r .tation. to which it i. 
logically conn.ct.d dir.ctly or indir.ctly through .aid 
•tation. to which it i. phy.ically conn.ct.d; mean. 
15 r..pon.iv. to th. establishment of a conn.ction with 
anoth.r .tation to trana.it .aid data from .aid routing 
tabl. to .aid oth.r station, and to r.c.iv. fro. said oth.r 
•tation data in th. routing tabl. cf that .tation; m.ana to 
tran.«it to oth.r .tation. within th. n.twork, through 
20 oth.r .tation. to which th. .tation is phyaically 
conn.cted, data relative to change, in the logical .tatu. 
of the .tation within the network, and to receive through 
other .tation. to which th. .tation i. phy.ically connected 
data a. to chang.a in the logical statu, of other stations 
25 within the network; and Beans to update the routing table 
in accordance with data received fro. other stations within 
the n.twork. 

At least a proportion of the stations within a 
dynamic conferencing network of the above stations oust 

0 have a capability of simultaneously establishing at least 
two independent physical messaging connection, so that they 
can act a. bridg.s within th. n.twork. without such 
bridg.., only two .tation point-to-point communication is 
po«.ibl.. Any .tation capable of only a single messaging 

5 connection must be connected to a bridge. Any bridg. 
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■tation aust hava at - 

-u 1P1 . ....., ln , *. it. 

rlooro 1 l. , .l.pii fl . d bl k 
•lcroco^ot.r foroin, . , t . ti „ .„. . „ . " C dU « r " °< 

conferencing; and ■tation during 

> invntlon. od " i « , ' i «'> •« « oonfor.no. utlli !ln , th . 

prow.. :t; t .L^:r °; r lnv - ti °" - 

portion or ott.nolon „, ,k * *" lnt '»"l 

-«ch 1. tot provl d .d "•• ">•»•■ °< • -t.tlon 

~. . . t .tio„. r::: rnrrT- 

o.rt«l„ .i nl . u . oopobllltl.. " "»"" »- roqoiro. 

• control proooooln, onlt ' " "T "** ld " 

-"•"« — mtUoo.'^ v r.:.; o™^ 1 : 1 "" 

Porlph.r.1 lnt.rf.co throo,h »nioh It 

=o»„„l c .t lo „ UnJt „ lt „ '* ,hlcB 14 ••t.bli.h . 

oopobllltlo. i„ „„ , . " t " 1 ° n " 

Wth othor ototlo^. « CO -"" lM "°'> «— 

-roly . SI'. I C *° 0^,, * r " h " '»•» 

z a aeaa end in a network to be for».d t„ «,« 
an exe«piary etation k roraed. m Figure l, 

interface 7 and int , " h<1Vln9 *" ">™<*"no„. 

e 6 ' and interfaces 8 and io to two ai.. 
network. a and fc. ° dlff ««nt 
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R.f.rring to Figur. 2, th. principal l.v.l. of 
..rvic. provid.d by a .tation during conferencing . r . 
illu.tr.tad. Thu. at th. hicha.t l.val 1. t*. UMr 
int.rf.ca ..rvic. la by ..an. of which a u.ar co-unicata. 
with th. ay.ta. and tha ..rvic. vhich it provid... Th... 
..rvic. will be characterise of tha .y.t.., do not for. 
part of th. inv.ntion, and n..d not ba d..cribad furthar 
•xcpt to indict, that th.y «u.t be .uff ici.nt to provid. 
•cc... to lov.r l.v.l ..rvic... a .ub..t of th. s.rvic. 
provide by a .y.te. .bodying th. pr.cnt inv.ntion i. 
that of ayatan conf.r.ncing ..rvic. 14, which in turn ne.d 
to utilixa cc.unic.tion. intarfac -rvic. 16 provid.d by 
tha ay.t.., which will d . p . nd upon ^ intarfac. 
availabla; in tha exa.pla ahown in Figura l, tha.a aay 
15 includa aarvica. ral.vrnt to tha intarfac. 6, 8 and 10. 
Tha.. lattar .arvic. ara charact.ri.tic of th. int.rfaca 
provid.d, and again for. no part of th. inv.ntion bayond 
that th.y ar. ad.quat. to tha data tran.far r.quirament. of 
th. conf.r.nc. ..rvic.. Llk.wi.a, the actual phyaical 
20 tranafar of data through tha intarfac. will be controlled 
•t a protocol l.v.l 18, th. protocol, baing a.tabli.had by 
tha co«unication. Int.rfaca aarvica i« ln accordanca with 
known tachniquaa. Again, tha only require.ent ia that a 
protocol ba utilized capabla of trana.itting data in tha 
25 for^t required by tha present invention. sine, a. will 
be «een, thi. data ia of a si.ple and United nature, tha 
nature of the data to be paaaed betwaen conference 
participant, will normally be determinative of the 
cowmictiona faciliti.. required, if only ai.pie 
30 «e...gi„ 9 cpabiliti.. ar. required, the .ini.u. 
reguir..ent is th. capability of paa.ing ei.ple a.a.ag. 
packet, which uy contain .ither data relating to 
confarencing control in accordance with the pre.ent 
invention or actual .e.aag. data. with the exception of 
35 th. ay«ta« confarencing ..rvic. 14, all of th. abov. 
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r«juir«.„t. b. fulfill^ by . .tati on k 

izzvrr ,nd h - rd - To;; 

llaltad to 7' ' tand * rd ' inV -" tio " i- 

li.ifd to u.. 1„ conjunction th.rcvith, .nd It 1. „I! 

5 n.c.ary that all . t . t i on . to ^ conf.r.n c J^ " 

I' "" -i.cu...d and can be program.* to 

i-pl—nt th. .y.t.» conf.r.ncing ..rvlc... 

10 .nabl. « SL*^^ aPPllCati °"' a ut ^^y progra. u .. d to 
.nabl. « .t.tion to partlclpat. In th. conf.r.ncing .y.t.. 
and to provld. th. conf.r.ncing .ervic. will ..tabll.H ! 
Proc... or cll . nt Appllcatlon lnteracti • w t ; t b h li '^ 

•PP icatlon progra. int.rfac. (API) or th. operating 
.nviron,.nt und.r which th. progra. 1. run, and up I 

» Proc... (N .twor)c Manager, , or Ban<lglng . confere „ ce ^ 

1:;;" lshes (IP c, 

Network Man.g. r In a .ann.r approprlat. to th. op.ratlng 
anviron».nt, for .xa.pl. 8hared Beaory er " tlng 

20 orct^ , ?" NetV ° rk Man<19er ^ tUr " Createa ^ .or. 

Lint PMd ' nt thrMd " (PDT) t0 ha " dl - th * ~ti« 

-alnt.n.nc. and t.r»ination of a phy.lcal lin* to anoth.r 

•tation. Each POT can h.ndl. only on. .uch lin*, and thu. 

n^! r " PDT ' " n<C ""^ to *.ndl. th. 

25 , Phy8lCal llnkB e8tabll8he < * th. .tatlon- 

« typically ..ch pot will handl. a different ecu ni cat ion. 

ZZZ ; hlCh 8tati ° n Pr09 " Med t0 P " V "" - 
....ag.. and handl „ reqUMtB recelved rroa 
application through th. API. 

30 th. , dCtail " ° f Pr09raB a " P" vid « d ««.r 

the following d..cription of th. natur. of th. . y .f. 

conforming ..rvlc.., in th. light of which th. program i. 
larg.ly ..lf-.xplanatory . ^ 
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Th. nature of the . y . tM conf.rencing Mrvlc#- 
beco-e .or. apparent fro. th. follovino «n V 

..t. bll . h ». nt and oparatlon c r „ on ; f 

:,vo lvi „ 9 . ultlpl . . tatlon . . ach prev ~ - izjz;;::z 

* -n o^tin, . y . t .. provldlng th- ^iUt^ 

It 1. a..u«ed that work station. A, B, c D E * p 

-fSTt.?^ ™- capaMntia. 

10 with ' lnV * ntio "< — «. programed 

10 with a progra. product in th. for. of a cosiest! on. 
application providing operating mymtmm TJtZli 
i.pl...nting th. conf.r.nclng ..rvlc.. ^^H^ST 
of th. conf.r.ncing operation will now b. di.cus.ed 

ADDITION OP NODES TO NETWORK 
" n " 1S lnltlally " 8U - d «»t three .achin.., A, B 

aupoor't r "T 1 " 9 tt * COBauni " ti — -PPli«tion and 
support the protocol, shown in Pig^e 3 A. i„ Flgure 3A 

(and .ub.agu.nt rigur..) , th. delation (T, rep^e-nt. 
th. capability of . Bachine (atation or ^ ' 
2 0 . coaaunic.tion. link vie . Tok . n Rlng (tradeBarJt) J££ 
to which a ..chin, i. connected, utilizing an appropriate 
protocol, th. de.ignation (E) r.praaant. th. capability of 
a station to establish a ccunication. linJc via an 
Eth.rn.t (trade.ark, network to which a Bac hine i. 
2S connected, utilizing an appropriate protocol, the 
de.ignation (A, represents the ability to establi.h an 
asynchronous communications link, using an appropriate 
Protocol, typically vie a BodeiB and th . pufallc 
telephone network, and (O) represents the ebility to 
30 establish so- other for. of communications link utilizing 
a protocol appropriate to the nature of th. link. Each of 
th. protocol, utilized mu.t be capable of providing 
guaranteed, ordered and error free delivery of ....eg.. on 
a point-to-point ba.i.. The de.ignations LI, L2 (and L3 
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where applicable) identify independent physical link, of 
the abova claaaaa which can ba managed by aach atation. 

Whan tha aachinaa atart up, all tha links LI, L2 
ara put in a atata waiting for any protocol-level 
connection raquaata from othar aachinaa. At thia atage 
thara ara no networka aatabliahad yat. 

Suppoaa aachina A wanta to connact to aachina bP 
Machina A knowa that it can connact to machine B through 
the Tokan Ring protocol. Thua it iaauea a protocol-laval 
connection request on LI, changing tho atata of LI as a 
aids affact. 

Aaauae aachina B accepta tha connection r equest. 
Then aachina A and B now eatablish a protocol-level point 
to point connection SI (See Figure 3B) . 

15 Botn "chines will go through a handshake sequence. 

The first step of the handshake sequence is for the aachina 
A initiating the connection request to send a special 
aeaaage S2 (CALLER_IDENTIFI CATION) to the station B at the 
other end of the point to point connection (Figure 3B) . 

20 In th e CALLER_IDENTIFICATION aeaaage, A lnaerte 

soae of Its own hardwareldataila. which Bay 'include some 
user information useful to a user of machine B to determine 
whether to set up a user-level connection. 

When B receives the CALLER_IDENTIFI CATION message, 

25 and processes it, it sends back a CALLEE IDENTIFICATION 

message S3 and Insert s siallar inf ormation*... This is the 
second and the last step of the handshake. The above 
procedure and the resulting network are shown in Figure 3B. 



- 9 - 



Now A know, that, through line LI, it Is directly 
connected to B, B knows that through its L2 link, it is 
dir.ctly connected to A. A and B can sand messages to aach 
othar through this point to point physical link. Ths 
5 contants of tha routing tabla in Machines A and B are as 
follows: 

TABLE 1 

Machine A: LI -» B(d) 

Machine B: L2 - A(d) 

10 where (d) means directly connected. 

C now wants to join the meeting held by A and B. 
C knows that It can reach A through the Ethernet protocol. 
Thus it issues a protocol-level connection request on L2. 



15 



Assume machine A accepts the connection request. 
Then machine A and C set up a protocol-level point to point 
connection Sll (Figure 3C) . Both machines will go through 
the handshake sequence. C sends the CALLER_IDENTIFI CATION 
message S12 to A. When A receives the CALLER 

IDENTIFICATION message, and has processed it, it sends back 
20 the CALLEE_I DENTI FI CATI ON message S13. This time, A puts 
its own information as well as machine B's information 
inside the message S12. 

When C receives the CALLEE_IDENTIFICATION message 
back, it knows that A is connected to B through another 
25 link in A. Thus C knows of B's existence in the network. 
C will update the routing table, noting that through its 
link L2, A is directly connected and B is indirectly 
connected via A. Thus C and B are "logically connected". 

After processing the CALLER_I DENTI F I CATION message 
30 froa C, A has to inform all other network nodes to which A 
was connected about the addition of C. A does this by 
broadcasting a NEW_N0DE(C) message to the nodes (in this 



c... only B) . A ..nd. out th. .14 to B through it. 

link Ll . 
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When B receive, the NEW_N0DE(C) message fro. A 
through it. link L2, B know, that another node ha. joined 
th. network, which i. c. since the message come, from A 
B know, that C ^ B are logically connected through A b 
thus add. C into the routing table. a. the ....age new 
NODE(C) come, from line L2, B put. C into it. L2 entry. 

Thi. complete, the addition of node c into the 
network. The routing table, of all 3 machine, are updated 
and the content, are a. follow.: 

TABLE 2 

Machine A: Ll - B(d) 

L2 - C(d) 

15 Machine B: L2 - A(d), c 

Machine C: L2 -» A{d) , B 

where (d) means directly connected. 

The above procedure, and the re.ulting network are 
illustrated in Figure 3C. 

20 As.ume now that another network exists between two 

-achlnea, D and E. The routing table entries for the 5 
machines residing in two distinct networks are as follows: 

TABLE 3 

Network l: 
25 Machine A: Ll - B(d) 

L2 - C(d) 
Machine B: L2 - A(d) , C 

Machine C: L2 - A(d), B 

Network 1: 

30 Machine 0: L2 - E(d) 

Machine D: Ll -> D(d) 

where (d) means directly connected. 
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Wh.n E r.c.iv.a the NEW NODE (A b ei — 
D through it. link u, B ^ov. ^ 
th. n.twork, which .r. A, B and c since T 
fro. o, B know, that it i. lj.il",, M *" 9e C °~' 

• c though o. b thu. add .T : iit:t:° a ' b ^ 

fbl.. A. th. .....g. NEW HOOK (A 3 C> a" , 0 \ 

« Put. A, B and c into L1 . ' 

fro. 0 B A h.Vt P o r Tr ln9 CALLER - ID ^"CATIOM ... Mg . 

NEV_NODE(D,E, ...saga to all nod., to which B wal 
coveted prior to ..tahli.hlng th. connection with 0 < ln 
thi. c... „od.. A and c, . B loo*, at th. routing tab . 

15 Thu. B *n„d. out th. .ee.ege S25 to A and r A 

linX L2. " d C thr °"9h its 



20 



25 



30 



through ^uTTTy^ NEW_NODE (0,*, Be .sag. fro . B 
gn link LI, A know, that other node, have joined 

Tri n : ; : rk ' vhich are ° and »• *- — 9- cot: 

fro. B A know, that it i. logically connected to D and E 
through B. A thu. add. D and E into it. routing fbl. J 

r-z r~ ;r L r r A - °< - : 

C.. w.ll. xnu. A looks up 

th-t ^..ag. can b. ..nt to c via link L2. a r.aenda th. 
«..ag. NEK_NODE<D,E, to C through it. link L2. 

Kh.n c receive, th. NEH_NODE(D,E) m...ng. f ro » A 
through it. link L2, c know, that other node. hav. je in.£ 

TrV: 71' -hlCh ° ^ *' Sln " «- .....g. costs 

fro. A c know, that it i. logically conn.ct.d to 0 and E 
through A. c thu. add. D and E into th. routing fbl. J 
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the ■••sag* NEH J*ODE(D,E) comes from link L2, C puts D, and 
E into the table entry for L2. 

This completes the merging of the tvo networks. 
The routing tables of all 5 machine are updated and the 
5 content* are ae follows: 

TABLE 4 

Machine A: LI - B(d) , D, E 

L2 - C(d) 
Machine B: LI - D(d) , E 

10 1*2 - A(d), C 

Machine C: L2 -+ A(d), B, D, E 

Machine D: LI -> B(d), A, C 

L2 -> E(d) 
Machine E: LI -> D(d), B, A, C 

15 where (d) means directly connected. 

The above procedures and the resulting network are 
illustrated in Figure 3E. 

DELETION OF NODES FROM NETWORK 

The following exemplifies how individual nodes on 
2 0 the dynamic network can disconnect from a network, assuming 
a network topology as shown in Figure 3F before anyone 
disconnects from the network. The connection table 
contents for nodes A to F are as follows: 

TABLE 5 

25 A: LI - B(d), C, D, E, F 

B: LI - C(d) , E 

L2 - F(d) 
L3 - A(d) 
IA - D(d) 

30 C: LI - E(d) 

L2 - B(d), A, D, F 
D: LI - b(d) , A, C, E, F 

E: LI - C(d) , A, B, D, F 



I > 
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F: « - B(d). A, C, 0, Z 

The aequence of event., .u -po 8lno + Hm4 . , 
to di.conn.c-. it..ir fro. th. n ,t^ i ° 
broadca.t. . LEAVE_NBTWORX JL^T'*" T°"' ° 
network. Thl. i. diff.^-. ** ln * id€ 

to .u _ „ ..;.r; r r . ™ res- °" 

•xplainad lat. r. ' dlW,rwc « "Hi be 

every node inaida tha network win „ 
—aaga, and updat. it. routing table J, P " ^ 
routing t.bla. oecce. M , "I ' ^ tha 



B: 
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25 



30 
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routing tabla. beco.e« a . follow.: 

TABLE 6 
L1 ~ B(d), D, E, F 
LI - KULL(d) , E 
L2 - F(d) 
L3 - A(d) 
L4 - D(d) 
LI - E(d) 

L2 - B(d), A, D, F 
" - B(d), A, E, F 
LI - NULL(d), A, B, D, F 
F: LI - B(d), A, D, E 

All tha noda. inaida tha natwork raaova c fro. 
their routing tabla. For phy.ical llnJta inv \ «= 

directly connected node, . HUH, 1s put ln tha tabl . J h 
that only logically connected nodes J JlT^ Z 
Physical link. The routing table entrie. for node C are 
not cleared. This i. eV€n though " « ' 

9~ any .ore outgoing .... aoaa , it.^ 

naed. tot, " ^ ^ '—ion at! U 

i Tctll , " ^ lBP ° rtant t0 **• ^.t once 

« --chin, (.ay, c, ia.ua. tha LEAVE.NETWORK .....a. that 

^.IVt" ^ " C - 1V - " y '°" *~ «»• < ~ * "y 
«t«n«l nod... Thi. i. o. cau . e c , ^ , LEAVE 

-H«V0RK a... ag ., ia no lcnger recognlzed 



- 16 - 

la that it has only ont ACTIVE physical link before issuing 
the LEAVE__NETWORX message. Node E having determined that 
it is not acting as a gateway, enters a state that waits 

for a message REQ_TERM_PHY LIHX from the other end of the 

link. When the message arrives, node E replies with a ACX 
_TERM_PHY_LINK (AGREE) message, agreeing the termination of 
the physical link. Both ends of the link then terminate 
the physical link, and node E now physically disconnects 
itself from the network. 



At the same time, node B detects that LI is no 
longer physically and logically connected to any other 
node. it sends out the REQ_TERM_PHY_LINK message to node 
C. 

When the message reaches node C, C may be still 
processing the termination of link with E (LI at C) . Thus 
it may determine that its gateway function still continues 
(with E) and cannot terminate the physical link with B. In 
this case, Node C will respond with the message ACK_TERH 
_PHY_LINK (DISAGREE), thus rejecting the termination of the 
link with B. 



Node B, receiving the negative acknowledgment, will 
NOT kill the physical link, even though it could. B will 
then periodically send the REQJTERM_PHY_LINK message again. 
Node C should reply ACK_TERK_PHY_LINK (AGREE) immediately 
its role as a gateway has ceased. 

During the time that C has not been physically 
disconnected, any machine joining the network from node A, 
B, D and F will cause a NEW_N0DE message to be broadcast. 
Node C will NOT be sent such a message from B, because B 
knows that on LI, nobody is on the network any more (even 
though C has not been physically disconnected because it is 
still processing the disconnection with E) . 



5 
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Optionally, after several trials, B can determine 
that tha gateway on tha othar end (C) haa failed to 
respond, and terminate the physical link unconditionally. 
B can do eo because it know, that the machine, on the other 
end of the link (C and E) have already left the network. 



13. After B and C have completed the disconnection of 

the physical links, the contents of the connection tables 
on all the machines are as follows: 

TABLE 8 

10 A: LI - B(d), D, F 

B: L2 - F(d) 

L3 - A(d) 
L4 - D(d) 
C: L2 - NULL '(d) , A, D, F 

15 0: LI - B(d) , A, F 

E: LI - NULL(d), A, B, D, F 

F: LI - B(d) , A, D 



Even though on machine E, B still appears on the 
table entry, this does not matter since the user of machine 
20 E has decided to leave the network. The application can 
send a command to the communications support to clean up 
all table entries once the disconnection is completed. A 
similar procedure is carried out in respect of C. 



25 



Unexpected network link failure may be handled 
similarly to voluntary withdrawal as described above. An 
example of the procedure is as follows, assuming the same 
network topology as shown in Figure 3F, and connection 
table contents as shown in Table 5. If the link between B 
and c drops unexpectedly, both B and c detect the 
30 unexpected drop, and find that the link cannot be 
recovered. 



0 
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Th. original n.twork i. nov .ffctiv.lv < , 

two ...n. r and lnd . p . nd . nt n . twork .. ' P v Ut l»t» 

by -Chin.. A, B, D and P .„! "h* forMd 

' and tn * "«tvork forced k« 
«c h in.. c and E. sine. ..chin.. B and C detect tnl 
= drop, th.y ar. re.pon.ibl. for inforBing othw ^ B Tn 
th.ir n.twork. about th. lont link. 

For machin. B, it. link ri <- 

m u2l ..nd. out 2 LEAVE_NETWORK messages • LEAVE 

10 .HET^C, .nd LEAVE — NETWORK (E) . B broadcast. £ 

—.age. to all oth.r nod.. i„ lt . netwer)c J** 

A, 0 and P) . B than r,„ova. c and B fro. 

™Lr in " ° " d F ' ""^ ^tharta 
LEAVE_NETWORK ...sage, originat. fro. B or fro* C an„T 

th. nod., fro. their routing tabla entries. 9 

For ..chin, c, it. link L2 i. droppad. B v 
axa.inlng the routing table c knows that A B D and v 
on link L2. xhu. c .end. our 4 LEAVE network °" 

Mn_»mo*x tr > . c bmdmu th «... t0 ! ' * 

«- m lt . «... to ^. „. c 'l„ to r v ;-« 
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— t «.„ whether th. ^vc_„ mow ;'„ ™J 

Dro& ... . . AIter tho "".ege. hav. been 

th. routing table, for each wchine are a. follow.: 

TABLE 9 

As LI - B(d), 0, P 
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Bt L2 - F(d) 

L3 - A(d) 
L4 - D(d) 
C! LJ -» E(d) 

0« LI - B(d), A, F 

E: LI - C(d) 

LI - B(d), A, D 



F: 



MECHANISM OF MESSAGE SENDING 

One. a network 1. created, application messages can 
10 be eent between any nodes within the network. The 
recipient can be one single node, or a group of nodes on 
the network. 

The nodes on the network are identified by a 
Network ID. In this exemplary embodiment it is a 16-bit 
value generated on a run tine basis (e.g. when machine i. 
powered up, the communication application is started up 
and so on) . 

During the handshake operation when a node joins 
the network, the Network ID "of the newly joined node is 
20 broadcast, along with a nickname in the form of an ASCII 
string, to all existing nodes on the network, within the 
HEM_N0DE message. All the nodes on the network now know 
the sapping between the nickname and the network ID. 

All application messages are sent following the 
25 following procedure: 

If the message is too big, it is broken up into a 
number of fixed size packets; else the message is wrapped 
in one single packet. A communication attributes header is 
appended in the front of each packet. The header contains 
30 the list of Network IDs to which the message is to be sent. 
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A routin. in th. co«minicatl«n. ... 
providing th . conf . r . nclng -J^Z^ ,77" 

H.tvorK io. f and „ c . rtaln . vhat ^J^"*" 

involve to ..nd th. packet to th. r.cipi.„t 1 "* 

5 n.tvork configuration .. .hovn i„ rl £ 'Tin IT * ' 
<i*ure. . hovn vlthln brackat- ln Which th - 

N.tvork id of th.t nod. *h , «Pr—nt th. 

»ac>H«. ' routln 9 tabl.« for .ach 

■achin. ar. a. .hovn belov: 

TABLE 10 

10 Machin. A: L l: B(d, 12), 

C(i, 7), 
D(i, 3) 

Machin. B: L l: c(d, 7), 

L2: A(d, 4), 
D(d, 3) 

Machine C: Ll: B(d, 12), 

A(i, 4), 
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20 



0<i, 3) 

Machine D: r, 2: B(d, 12), 

C(i» 7), 
A(i, 4) 



30 



conn8ct( X lndic «t.s direct (d, or logical (1, 

connection., and y indicates the netvor* ID of the 
connected node. f the 

it. ° WantS t0 * M8Mga to 8 an < °> it check, 

it. routing tabl., and .ee. that both B and D can 1 

reacbed via phyalcal linJc L1 . Thujj c ° 
-nd .end. the packet out ONCE on link Ll. 

that thiri 8 """?" ^ ^ C ' ° n " 

tbat thi. -.. a g. i. Mnt to ^ B 

?; inco ' ln9 packet ' «« -X. 

wr-PP- i„.lde. since tbe pacK.t i. to be sent to 0 I. 

ZllL J*" ndS t0 °* " lo <*' «P -uting 

tabl. and .e. th.t D can be reached by lin* L3, and thus B 
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•and. th. packet (u.ing an exact copy of ihe pack* 
received fro. c) to D along link L3. whan D receive, the 
packet fro. B, it will procaa. it. Th.ra axi.t. . 
.achania. (di.cue.ad below) that avoida D fro. .ending tha 
5 packat back to B. 

Two critaria exi.t to determine tha phyaical link, 
involvad in .ending a packat. Thay are a. follower 

a) If the packat to be eent out is not 

originated from the local machine (i.e. the 
packet ia a received one, requiring 
reeending) , the packet is NOT sent to the 
physical link the packat was received on. 

U.ing the above example, when D receives 
the packet fro. B on link L2, it proceaaea 
it and finda out the recipient liat 
includea B. Thus, D look, at the routing 
table and find out that B can be reached on 
link L2. Therefore the packet is supposed 
to be sent out via link L2 . But D received 
the packet on link L2, so the packet is 
not resent. 

To provide another level of robustness, a 
packet is never resent when the packet 
received has the same originator network ID 
aa that of the receiving machine. This 
avoids any unexpected network error from 
having the result that the packet 
originator receives the transmitted packet. 

MACHINE ID COLLISION RESOLVING MECHANISM 
30 when the sy.te. is ueed in a peraonal conferencing 

anvlroiwent, and since in any practical aituation only a 
few people will be in a conference, there will be very 
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b) 
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littl. ch.nc. that two or »or. ..chin., win g . n . rat . tna 

" M r " n " tlM MtVor * 10 « S536 poa.ibl. value, 

if a aixt.en bit coda la uaed) . 

Whan a new node trla. to join a network, with a 
run-time network ID id.ntical to that of any one of th. 
noda. alr.ady in tha network, . network ID collision 
occur.. sine, all application ....age. ua. tha 16-bit 
network ID to id.nt.if y .th. .ourc. and tha de.tinationa, all 
natwork nod., must hava unique n.twOrk IDa. 

If th. nlcknaaea ara combined with th. network ID. 
it i. virtually impossible to hava collision on th. 
combination, but thl. increa.e. transmission overhead 
considerably, and doea not theoretically eliminate the 
poaaibility of colliaion. 



The following mechanism can be used to correct the 
network colliaion problem. Assume for example that machine 
A i.aue. a protocol-level connection requeat to machine B, 
and B accepta the requeat, establishing a px otocol-level 
link. Alao assume that machines A and B already have set 
20 up network, with some other machines. During the 
handshake, A sends th. CALLER — IDENTIFICATION message to B. 
Inside the message A includes its own network ID and the 
network ID. of all the machines connected to A prior to 
this connection. 



25 Tne "onanism requires the called machine (B) to be 

responsible for resolving any network ID collision problem. 
B processes the CALLER.IDENTIFICATION message. It checka 
to aee of ANY of the network IDa A haa sent in the CALLER 
.IDENTIFICATION message collides with any of the network 

30 IDs inside B ' . network. B has to check all network IDs 
sent by A in the message, since the network A is in and th. 
network B is in are merged together when A and B are 
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connected. Thus B has to make aura the nodes on the new 
(merged) network have no network ID colliaions. If there 
is no network ID collision, the two networks can be Merged 
and the handshake procedure continues. 

5 If there is a network ID collision, B is 

responsible for resolving the collision. B generates a new 
network ID that does not collide with any of the network 
IDs on the merged network. Instead of sending the CALLEE 
* _IDENTIFI CATION message, B sends out an UPDATE_NETWORKID 

10 Message. Inside the Message is the nickname, and the old 
and the new network ID of the node involved in the 
collision. It is the node in the network requesting the 
connection that is updated. Thus in this example, the node 
in network A which is involved in the collision is updated. 

15 B then proceeds with the handshake to complete the merging 
of the two networks, and B updates its routing table using 
the new network ID for the colliding node. Optionally B 
can wait for an acknowledgement from the node involved. 

A program used to set-up, control and implement the 
2 0 procedures generating the various messages discussed above 
and responses thereto is exemplified below in pseudocode, 
using syntax similar to that of the C language. It will be 
appreciated that details of the code will be dependent upon 
the operating and hardware environments within which the 
25 program is to be implemented, and will be readily apparent 
to those skilled in the art of programming in those 
environments. The pseudocode is written so as to be self- 
explanatory taken in conjunction with the description set 
forth above, and shows the various steps and routines 
30 required to be carried out by a program to implement the 
invention. Whilst some details of coding will depend on 
the characteristics of the hardware platform on which the 
program is to be executed, a program written in a high 
level language should have a substantial degree of 
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portability. 



to th. API. i„ T « bl . ... _ r Client Appllc« tlon 

of ....num. ot ?r r u " ln * *■ 

it. nnnoan, .nZ " 

tro. th. API. T.bl. , M TT, w PP * r C "*' 

CXl«t Appllctlon, „. itontitlLZ'J th. 

».t.» rt M.„. 9 . r anJ „. p ^ lnt ,* r ;* 1 *—•*•■ >«...„ th. 

»«-P OT _. .MM .....o.. "'t " " 9 * T" "* Pr •' 1X • <, 
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, TABLE 1 

/ 

/• ComlnltM 

/ ' 7 

Com|nit() / 
I 

. Initialize local machine 
. Create IPC 

. Create the process that runs the NeUork Mgr/PON 



Create a thread that waits on the IPC for any Inccml 



messages/events 



no 



. Create and format a message to Initialize corni software 
Then send the message to the i*wly created hVtimrk Mqr/POT 
process to Initialize the Network Mgr/PDI proems. 

. return 

) 

•••• The thread created the Comlnit() call is as follow. •••• 

/ # * 

/• CwnWaltEventThread() 

Coaxal tEventThreedf) ' 

while (not terminate) 
( 

. Walt for message from IPC. If there nrr no message. 
In the ire, blocks Itself until a messnq* cr™ 5 i,,' 

. Inform Client App. about the Inromlno nwHtsoV 

. return 



/ 



/* ComConnectf) 

/ 7 

ComConnectf) "7 

. Create and Initialize a message for connrrl rrqu^r 

. Send the connect request through IPC In IMwnrf: flnr/Pni 
process. ' 



. return 



/•^ Co^)lsconnect() ^ 
Co«Clsconn«t() ^ 
. Create and Initial!.-- a mrssao* for disronnm rrr,ti*ni 



- 26 - 



Seethe disconnect request through ir C tr HeUorfc ll gr /mi 2CSD-29 



return 



/* ComAcceptJolnNetReqf) / 
ComAcceptJqlnNetReqf) ' 

/• This call Is made after a SOMEONE REQUEST TO JOIN NFIWORf 
I <S 5 * nt from **t*ork Mgr/POT process to AP| ," fln ri Client Ann 
^ls informed and decided to rJlow the join network renuesl. 

. Create and Initialize a message for accept Join net req„est 
. Send the request through IPC to Network Hqr/POl process. 
. retun. 



/• ComReJectJolnNetReqr J. 

I : 

ComReJectJolnNetReqf) ' 

/• This call is made after a SOMEONE REQUEST TO JOIN KETWORr 
<S sent from Network Mgr/POT process to API,* and CHrnt App 

# 1s Informed and decided NOT to allow the join n-Uork 

* request. 

7 

. C eate and initialise a message for rrirei join iwi r*qn**» 
. Send the request through IPC to Network llnr/PPI P r 0 rr«;<. 
. return 

1 

/ , 

/• ComSend() J f 

ComSendf) - - 

I 

. Create and Initialize a message for send d/ti/i rpqimo 

. Send the request and the data throitqh irt to Melwnrfc Hqr/PD! 
process. 

. return 

) 

/ :., 

/* Co»ler»lnste() /, 

/ ', 

CoaTeminate* ; 

\ 




* This call is made when the Client App. tprminnt's •/ 2050.120 
Create and Initialize a message fcr terminate rpqiieM 
Send the request through IPC to Network MQr/PO! process, 
destjc^ the receive event thread 
close the IPC 
return 



TABLE 2 

) Create the Comm •/ 



/• Walts for the result: wait for message HUT RFSIIU '/ 

/• Connect to a person •/ 
ComConnect () j 

/• Walts for the result: wait for message CONNEri RCSm.1 '/ 

/• Send data •/ 
ComSend(); 

/• wait for event: process event depenrilna nn the message 
type. 

7 

We1t4Event( ftevent ); 
switch (even t.eventtype) 

{ 

case S0M£0NE_J0!HEDJ1ETW0RK: 

/• Display a dlaloo to i?s*r t tnmemt* joinH 

* the network 

V 
break; 

case S0ME0NE_lEFT_NETV0RK : 

/• Display a dialog to user, someone left 

* the network 

V 

break; 
case INC0MING_0ATA: 

/* Process incominq data */ 
break; 

case SOHEONE_RE0UEST_T0_JOIHJinwORK: 

/* Display a dialog to tisrr, Infonnino him 

* that someone wants In jnln il»n nriwnrl:. 

v 

tf (bAllowtoJofnMet) 

( 

ComAccf ptJo i nNM Br<|( ) ; 

) 

else 
( 

ComBe.teetJoinll<;tR*n(); 

I 

break; 

default: 

break; 

) 



/• Client App. terminates. First disconnprt frnm network '/ 
Com0isconncct() : 

/• Walt for disconnect result 7 

/• Terminates •/ 
Co»Tenfttnate() ; 
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TABLE 3 

/* maln() function here Is the first function called wImmi JkiworL "n»7 
• POT process Is created. 2050^29 
V 

ma1n() 

( 

. connects to the IPC created by API 

wait for message HSGJNI T JOf*t_SOnWARE from API 
. Initialize various components 

. creates the POTs that ere specified by th* cllrnl npp. 
(I.e. call the appropriate POTcrentf() routines) 

. send the message MSGJHII_CfrW JESUIT lo API fhrmmli IPC 

. call NetworkHgrQ 

. return 

) 

NetworkHgrf) 

/• This function loops until the terminate messnnr from An 
• Is received. 
7 

while (1) 
( 

. wait for messages on IPC from API . If there nre no 
messages on IPC, blocks ItseM until a mrssag* comes 
in. 

switch (messnqe type) 
{ 

cose MSr,_CONNECT: 

. check what protocol and hardware 
adopter should n^^rt If* ronn^c' 
to the user. 

. format the MSG_mT COHlim and send 
to the appropriate PHI Inr nrorrssinci 

break ; 
cose MSG DISCONNECT: 

7 format the HSG^POT niSCOHHrCI and 
send 1t to all active mis (sine* 
this message means disconnect inn 
the client app. from tl»r rWworL, 
which Implies disronner I inq nil 
physical connections. 

break; 

case MSG ACCEPT COMHEn REO: 

" perform netwoik 10 rollir.inn rhrrl- 
(pseudocode omitted hpre) 



format an acro«5-netwnrl- m^snoe 
CAU EE_ IDFHIir IfAT |W| wilh fhr 
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hAcceptCnl I flag set to I HUE. 

. form/it the internal *w»ssnn r 
MSG_P0T_SEN0 0AM and specify 
the CAUEEJDENTIFICATIC.H messaqe 
as the data to oo out . 

. send the messaoe M$G_rni SEW) DATA 
to the approprlnte rOT 

/■ *ow caller nnd anyone with the 

* caller before the connection Is 

. • established Join the network. Mas 

# to let the local client, app and 

# other stations on the network to 

* know about thfr. 

7 

. format the across-netwnrk messnoe 
HEW_M00e with the 
caller's nnmc nnd netwnrl- m. 

. send the across-network message 
to all active POIs, except tltr 
Just-connected one, via the 
MSG_PDT_SEN(M1Af/\ request . 

/• Add the caller's name nnd network 

* !0, provided in the 

* CAUERJOENTiritATIOH message, 

* Into the routing table 
7 

. if (caller ha*, ronnrcl'ri In <nmrnnr 
prior In nwikiwi l.hi« 'nttnrrtinn) 

I 

. call Snnw»h>wlUrr*Ion() 



/* If the hnrdwarr ran support. 

multiple connrrtinns timiilf nnemiOv 

• then create a n^H mi *f fltr «nmr 

* protocol 

7 

if (hardware on which ronn<*rttnn i-, 
establt5hrri support* mttM iplr 
connection) 

I 

. crent' n new mi 

(i.e. rails th* appropriate 
mirreatef) rmitfne) 

break; 

case MSG REJCCT COHHECT REO: 

. format an across-netwnrk mrssno'* 
CALLEEJOFHHf ICAT(M! with thr 
hAcceptCall f I /in <et In TAISf. 
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. format the Internal messnqe 2C£0^~^ 
MSG_rt)I_SENOJ)ATA and specify 
thrCAllEMDfWT!FICAT|MI m*s*noe 
as the data to no out . 

, send the message MSG_PPI SFfiO DAtA 
to the appropriate mi 

/* Since the user hns refused the 

* connection, the physical connection 

* is useless. Kill the connection 

* established 

7 

. send the message HSGJD? DlSCONNFCl 
to the appropriate POT 

. send the message MSG_PTH JERMINATf 
to the appropriate nil to Irrminatr 
it. 

. create a new H)T of the same protocol 
to wait for the connect rrquest from 
someone (i.e. calls the PWcreatf() 
function) . 

break; 
case HSG_SEN0_0ATA: 

. format the internal message 
HSG_rOT_SEHO^OAlA and specify 
the'deta referred to In MSG SENfMJAIA 
as the data to go out. 

. look up in the routing table. Find 
the POls the data rrr.r i pirnt.s are 
connected to. 

. send the message MSG_r01 SFMO OAT A 
to the appropriate Wis 

break; 
case MSGJE RUINATE: 

. terminate all active PHI'. 

. return to mainf) 

cose MSG_roT_p»Y_coMiicr.i^siicnF«;srni : 

. format a message 
MSG CONNECT RE5«I T with return rode 
OK " 

. send the messaoo !o ATM through 
IPC 

. check the CAUrEJOEfMinr.ATinfl 
message received. If thrrr are 
any other user* nlready connected 
to the caller, call SowWh-wllsers lon( ) 

Create ft new m I nf »br same protocol 
In wflif 'or rnnnrrt rrniir'.r'. from 
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| /• end'wMie(l) V 



someone (f.,. fn ,, 5 m, frrfltr(J rrnf) 
routine). _ 4$\ :j J**w J 

break; 

case MSG_P0T_PIIY_C0NNCCI rAlLED: 
. format a message 

MSG_CONHFCT RESHM with return rode 
FARED 

. send the message | 0 API Ihrouoh 
IPC 

break) 

case MSG^POT^OISCONNECT^SUCCESSnil . 
. format a message 

MSGJHSCOWNECT RESUU will, return 
code OK 

. send the mes*aoe lo API Ihronqh 
IPC 

hreak; 

case MSG_POT_DISCONNECT_ TAILED: 
. format a message 
MSG^DISCONNECT RESUI 1 »UI> rrluru 
code TAILED 

. send the messnne t 0 API Ihrouoh 
IPC 

break; 

case MSG_PDTJ?ECEIVED_DAIA: 

. call ProcesslnD.ua() 

break; 

case HSG^POI^COHMECTIOM/AILFn UHf XPTCTEDU : 
. for the mi fh.il lli'r" t miner I Inn 
failed: 
f 

. find oul all ii'.er-. f miner led 
virt I he f,if |r»r| pnr 

. for every u^rr, fornwil rt 

use sofieonr rrr i MFi*nn>; 

and send to API . 

Also format an arross-nptworl- 
message LFAVEJIFlwnnr «Hh 
the user's nomr nnd net.wnrl: 
ID. Broadcasl Mi* 
LEAVEHFTHORK mefsaoe to all 
rpmoinina «r f i*»e PT1U 

I 

break; 

default: 

br^ok; 



I 



return; 

The code that processes Incoming data ar* follows 



| ProcessInOetaf) 

i I 



switch (Incoming data type) 

case CUENT_APP_DATA: 

. format a message MSGJHCOMING DAfA 
with the incoming data 

. send the message to API through 
IPC 



i ( 

i 



if (message is to he forwnrnVfl : 0 *thr»- 
stations as wel I) 



look at the receiplents list, 
rind out the PDTs involved to 
send to all thos* r^rHpl^nU 

except the POT that the data 
is received from, format thr 
message MSGPOT^SEND^ DAIA 
with the rlTenl~rtatn"rprrlvcd 
as the data to n* sent out, and 
send the MSG POT SEND DATA to 
those POTs involved. 



. return 
case CALLER^ IDENTIFICATION: 

. extract the user's nam* and informnf ion from 
the messaqe 

. format a message 
MSG_SOMEONE_REQUESTEI)_JOIN_ NETWORK with ihr 
caller's name and Information, as wrll as 
the POT on which thp fAllFR inrw fr ICAT I Of I 
message Is received. 

. send message to API r.hrnnoh IPr 

. return 
case NEWNOOE: 

. add the user's name and network If) onto the 
Network Hgr's routing table, and word which 
POT the NEW_N00E messng- is 
received from. 

. format a message MSG SO'tONE JO I NEDHE TWORK 
with the user's name in the m*ssaop. 

. send. the MSG_S0ME0Nf JOINTO flFIHORk nwssnor 
to API through IPC 

. check In the rotitlnn t/ihle any olh^r n)U 
that ar<? active. If sc, rr-hronrirn<» Ih* 




NEW_NODE message to those POl< 

vla~a MSG_rt)f_SENtH)A1A requ-M. 2f£OfT20 

. return 
case LEAVE_NETWORK: 

. remove the user's name nnd network in in thr 
Network Hgr's routlnn table. 

. format a message 
HSGJOM0NE_lEFT_NETWRK 
with the user's name In the messaqe. 

. send the MSGJOMEONE LETT NETWORK messaoe 
to API through IPC 

. check in the routing table any other PDI* 
that are active. If so, re-broadcast the 
LEAVE_NETtfORK message lo those POU 
via a MSGPDTSENDOATA request. 

. return 
case REQ_TERM_PHY_l I NIC : 

. depending on network topology: 

If (OK to terminate link) 

. send an across-nelworb 
ACK_TERM_PHY_l INK message via 
MSG~POr_SENO~DAIA request on 
the approprinfe POT 

. send message MSG POT I ERM I MATE 
to the disconnected PfH 

) 

else 
( 

. discard the me^nor 

) 

break; 

default: 

break; 

) 



return; 

) 

The routine Some NewUsers Too () Is as follow •••• 
SomrHewthersToo() 
I 

/• When the caller's connection request \% ncreptrrl, 

* the caller 1s allowed to join the netwnrk. If 

* the caller Is already connected to sow other 

* users, they automatically are allowed In loin 

* the network too. 

* The sa«e applied to the caller's slrir. when ralir^ 

* accepted caller's request, the caller ( i|*n Irl 

* all the users already connected l<? "all"* In l*i 



) 
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• tKfm know eb.o U t c«ll« «,d „j frj conned in 

* ealle. 

This routine process those new usrr*. 

7 

. add all the users already connected to thp rnllrr 
to the routing table. These users* names and 
network IDs ere provided in the CALLER I0ENT inCAllon 
(or CALLEEJ0EHTIFICAT10N) message sen! hy callrr 

. for each user specified In the CALLER IDENf inrA? ION 
(or CALLEE_ I0ENT f FICAT ION) 
message (except caller Itself) 

. format a MSG_S0ME0NE_ JO ! HEO flETWRlc mr„ nqf > flnf1 < rnd 
. 1t to API through IPC. 

. format the across-network messno* NEH Nnnr with th* 
user's name and network If). 

. send the ncross-network messngr to all nrii^ mu, 
except the Just-connected onr, via thr 
^ HSG_PDT_SEND_OATA request. 

return 



The routine that creates POT Is as follows — 
POTcreate() 

( 

/• This Is a generalised routine. For different protocol* 

♦ Ait, 1 Pflrw * ters flnd «tua1 function names will hr 
different. This pseudocode is lo ri*mon<troi- i|„« 

* logic flow only. 
7 

. Jf (need to Initialize hardware) 
^ . Initialize hardware 

. connect to hardware, and acquire thr m.*n>rl rnsourr^ 
from the hardware for a new connection 

. create a message queue lo rec-iv* ri>ou^t< from fin won- 
Manager 

. creates a thread of execution, P01 thrrnriO 
. return 



POTthreadf) 
{ 

/•This thread performs the essentl.il function of I h* mi •/ 
. for the ne-ly acquired resources for a ronn.rt.oo, srnrt f 
Command to the haroWe In Pflf PARf f or „ conn „ f rrq|(r0 
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. exit loop 



Exit loop: 3 possihlle scenarios. 

1. Connect request accepted hy destination machine. 
Connection established at the user level. Can 
exchange data 

2. Caller from another machine Issued conned request 
and got accepted. Can exchange data. 

3. Caller from another machine Issued connect request 
and rejected. Walt for Disconnect request frnm 
Network Manager. 



I 

Issue can 

•Mle (1) 

{ 



and to hardware to PREPARE to receive data 



/• Check to see If there are «ny request <> from 
• network manager 

v 

. If (request in message queue) 

( 

. extract first message in queu* 

. switch (message type) 
{ 

case MSG_rOT_0lSC0NNEC!: 

. send th* nc ross- network 
messag* RFO TTRTI PIIY^UUK 
to the othrr rml nf l.hn 
physirnl link 



. wail for thr 

ACr irRft rilY I \m mr5«;noe 
from \hf nthrr rn»| . 



. Send the disconnect V i Til: 
comnvwri to I hr bnrdwnrr 

. hrenk; 
case MSG TOT TERMINATE: 

7 If'th* link is stilt active, 
send command to thr hardware 
to disconnect I hr physical 
link 

. terminate thr t hrrnd ol 
eircut ion 



. exit while loop 
case MSr»_TOT_SUJD DAIA: 

. Senfi I Iip clnta nn» 
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. unknown m^nor, ti\scnrri 

) 

|f (data received by h*rdw«r,.) 

. receive the data from hnrdwnre 



J 



. send message HSGJUT RECEIVED 0/WA to Network 
«s the data to he processed 

) 

If (connection dropped une*pec tfdly) 

send message 
MSG_P0T_C0NN£CT 
to Network Mgr 



send message 

MSG_POT_CONNECTlONJAIirO UfirxiTCICOl Y 
to Network Mnr 



} 

terminate thread or execution 



• \ 
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THE EMBODIMENTS OF THE IHVENTIOK IN WHICH AN EXCLUSIVE 
PROPERTY OR PRIVILEGE IS CLAIMED ARE DEFINED |SSS£ ? 

1. A computer workstation with the capability of 

participating at physical and logical levels in a computer 
conferencing network, comprising: 

at least one means for establishing and 
discontinuing a bidirectional physical messaging connection 
with another station having similar capability, and with 
which it is desired to network, according to a protocol 
permitting the establishment of such a connection 
responsive to a protocol level request; 

means establishing a network routing table at the 
station storing data as to other stations to which it is 
directly physically connected, and as to other stations to 
which it is logically connected directly or indirectly 
through said stations to which it is physically connected; 

means responsive to the establishment of a 
connection with another station to transmit said data from 
said routing table to said other station, and to receive 
from said other station data in the routing table of that 
station; 

means to transmit to other stations within the 
network, through other stations to which the station is 
physically connected, data relative to changes in the 
logical status of the station within the network, and to 
receive through other stations to which the station is 
physically connected data as to changes in the logical 
status of other stations within the network; and 

means to update the routing table in accordance 
with data received from other stations within the network. 

2. A workstation according to claim 1, including at 

least two Independent means for establishing and 
discontinuing a bidirectional physical messaging 
connection. 
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3. A workstation according to claim 1, wherein at 

least one M «n. for a.tabli.hing and discontinuing a 
bidirectional physical messaging cbnnaction 1. provided by 
a network into which the workstation is physically 
connected . 

«• A workstation according to dale l, wherein at 

least one «eans for establishing and discontinuing a 
bidirectional physical messaging connection is provided by 
an asynchronous interface to a switched telephone system.. 

3- A workstation according to claim i, wherein the 

workstation is allocated an network ID, and wherein the at 
lea.t one means for establishing and discontinuing » 
bidirectional physical Messaging connection is configured 
to transmit data in packets labelled with the network IDs 
of other etations to which it is logically connected via 
that phyeical connection and which are intended to receive 
the data, and to receive data labelled with its own ID or 
with the ID of etations to which it is logically connected 
via another physical connection. 

«• A software package including routines to configure 

a computer workstation, provided with at least one means to 
establish and discontinue a bidirectional physical 
messaging connection with another station, according to a 
protocol permitting the establishment of such a protocol 
according to a protocol level request, to provide services 
permitting it to participate in a computer conferencing 
network, said services including; 

a routine- to establish a ne. jrk routing table at 
the etation storing data as to other stations to which it 
ie directly physically connected, and as to other stations 
to which it is logically connected directly or indirectly 
through stations to which it is physically connected; 



• routine responsive to establishment of a 
connection with another station to transmit said data fro. 
said routing table to said other station and to receive 
fros said other station data in the routing table of that 
station; 

routines to transmit to other stations within the 
network, through other stations which the station is 
physically connected, data relative to changes in the 
logical etatus of the station within the network, and to 
receive through other stations to which the station is 
physically connected data as to changes in the logical 
status of other stations within the network; 

a routine to update the routing table in accordance 
with data received from other stations within the network; 
and 

routines to receive, transmit and relay messages 
over said physical connection. 
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